Cisco Networkers 1998

home *** CD-ROM | disk | FTP | other *** search

/ Cisco Networkers 1998 / Cisco Networkers 1998.iso / pc / talks / nwk06b / nwk06b.eml < prev next >

Wrap

Text File | 1998-04-24 | 51.0 KB | 870 lines

<HTML> <HEAD> </HEAD> <BODY> Okay, let's turn this around for a little bit. How would you go about protecting an internal resource, like the SMTP host that's out there? We've got various ways of doing it. Let's take a look at using IOS, the PIX, the IOS Firewall feature set, and the Centri to protect that SMTP host. First we'll take a look at IOS with just an access list. We'll start down at the bottom of that configuration. Access-list 111 permit tcp any to host 172.16.1.1 eq smtp. So if we apply that thing to the outside interface, that Ethernet 01, we will allow packets that say there's two source, or two destination port number 25 to enter that thing and go through the router. Same thing with this other one, permit tcp any host 172.16.1.1 established. What that's going to do is, if the internal machine that your SMTP host out there starts up a session going to the outside, you want to allow packets back in that have the acknowledgment bit set on them - also the thin bit set on those things. So you put that established in there, so now the packets can come back in. After that, we're going to go ahead and accept ICMP packets coming from the outside, so we have that third line. So now what's going to happen is the router will accept packets that are destined to SMTP through it from the outside to the in. It will also allow that mailhost to set up sessions outbound and allow the responses to come back in. Of course, an attacker will be able to craft a packet with the acknowledgment bit set on that thing and send it in by passing the access-lists. Okay, yes that can be done. If there is something better than that, why would you apply this to protect a resource? You do that in the case that you only want that resource to be used for only SMTP. In a moderately trusted external network, let's say you've got a bunch of people out there who not only want it to be used as a mailhost, but they want to be able to Telnet to it or FTP to it and store files on it, but your policy says, "No, don't allow that." This is a real good mechanism where you trust the people on the outside to not craft the packets to come in to attack it. This is a real good way to allow that router to enforce your policy. Okay, let's take a look at the same thing, same scenario, using the PIX now. Let's take a look again at this Version 4.0.7 configuration. The outside and inside interfaces, yes - the IP addresses, yes - we've got those. What we're looking at here are the bottom four configuration commands. The mailhost command - normally you would use a static command here. The mailhost command puts a little bit of extra security for SMTP on the interface there. So we're defining the external presentation of the SMTP host as 172.17.1.12. The internal - the real address of this device, the address that it knows itself by, is 10.1.1.2. The PIX can act as a network address translation to take care of this. The next couple of lines - first one, the conduit - this is starting to permit the port number 25, which is SMTP, to go through the PIX to that internal host. And it's saying it can come from anything on the outside. Again, conduit for TCP port 110, the POP3 protocol - if you want to use this thing as a POP server in your network. And finally, the ident protocol - remember I told you that was nasty. But if you don't have it in a lot of these applications, it will wait and wait and wait to complete the SMTP or the POP3 session until that ident D has timed out. Normally you want to allow this, normally you'll see a lot of resets of that, as the PCs don't support the ident D protocol, or the auth protocol there. So what's going to happen with this? Outside devices are going to be able to set up SMTP sessions inbound to the mailhost. The mailhost command in the PIX is going to watch these sessions specifically and only allow the seven generally acceptable commands to come from the outside. It will not allow things like Wizard or any of the other attackable commands to come through it. The IOS Firewall feature set - we've got another talk here at Networkers that goes into a lot of details about this. Let me just say that a lot of stuff starts happening when you turn a router into - or when you add the IOS Firewall feature set. First thing that happens is that the IOS becomes stateful. Normally routers just try and push packets through as best they can and they're not looking at the state of the packets, the sequence numbers, the flags, the sequence and ack numbers, the flags in the thing or anything else, they're just trying to push it through. IOS Firewall feature set changes this. It becomes very stateful. It watches all the sessions going through the thing. It also looks at some timeout periods. It also maintains a log of all the sessions, and can send these things out to an external server as well. Let's go through this thing pretty quickly. Again, this is explained a lot better and more fully in some other Networkers talks. First thing, we're going to inspect the audit trail. We're going to limit the DNS timeout to only 10 seconds. Why is this important? You don't want to send out a DNS query and then 15 or 30 seconds later get a response back if you know, absolutely certain, that the response should come back in from the trusted DNS server in under 10 seconds. So it's going to clip that thing off. At the end of 10 seconds, it's not going to allow any additional responses back in. The TCP idle time - 60 seconds. It's a watchdog timer. If someone sets up a TCP session through the IOS, if it's - remains idle for 60 seconds, IOS is going to send resets in both directions and stop that session. Those were global commands. If we go down now and apply an inspection name and put these things in a little list here called myfw we can override the global commands where we apply this thing. First one is with SMTP. We change that timeout to 3600 seconds. That's one hour. That might seem a little bit outrageous in most circumstances there. Another one - the TCP timeout is again changed, for where this thing is implemented, to one hour as well. Going down through this thing, looking at the very bottom of this configuration, we've got some very similar rules as what we applied to the PIX. That's smtp, pop3, and ident. So what we're doing is allowing those things to come in from the outside and then IOS is going to maintain the state of these sessions and apply the timers and the watches on these things as well. The Centri, again, it's stateful. It will watch all the sessions and maintain state of these things, make sure the acks and the sequence - the sequence numbers and the acks are incrementing properly. It's going to limit the SMTP commands that come through. It will also limit the characters that are inside of the Receipt To or Mail From commands, so that you can't have too many @ signs or too many exclamation marks. A few other things as well - since the Centri has a graphical user interface and it's run on top of an NT server, it was very difficult to get any meaningful configuration snips for this thing. So please accept just the drawing here. We've got some additional mechanisms. These things are like - rather than just having one rope hold something aloft, you've now got two ropes. If one of them breaks, the other one goes into effect and takes over the entire load. Let's go through these things and take a look at some other mechanisms we have to enforce your policy, if your policy says you have to have some amount of uptime. And a lot of these things have been talked about in prior Networkers, and I'm sure a lot of people will go through these. And certainly talk to any Cisco person about getting more information about these. The first one is Lock and Key. This is - can be very effective in a low-risk environment. What's going to happen here. Someone Telnets to the router, the router's going to check the authentication by sending that on, in this case a TACACS or a CiscoSecure server out there. If the authentication is accepted, then a dynamic access list will be allocated to an interface to allow that person, knowing that IP address that the Telnet started from, to be able to access an internal resource. You can apply some timeouts to this, so that it'll be closed down after some amount as well. Hot Standby Router Protocol - you've got this wonderful resource out there. You don't want to burden it with running a dynamic routing protocol or anything else. You don't want it to ever know that the network has changed. You can run HSRP between a couple of routers out there. One of them dies, the other one automatically and dynamically takes over that load. Again, Spanning Tree Bridging - as you can tell here, the graphics group - seminars group sent me a very large file of all sorts of icons and they said, "Use these in your Networkers presentation." I'm trying my best, I'm using as many as I can. In this thing what we've got is our resource out here going to a switch. One of the paths is forwarding, of course, the other one is blocking. If the forwarding one dies, the spanning tree will automatically prune it and go to a backup link and turn it into forwarding. This can be very effective also for maintaining a network resource, making sure it's part - always part of your network. Local Director - this is distributing a resource or a service across multiple servers. Local Director can maintain contact with each of these things, make sure they're up. And if one of them goes out for service or something, it'll prune that and allow the others - all new sessions to go to the other servers to maintain that resource. Distributed Director pretty much works the same way except in a wide area environment. It'll allow people who are closest to the server to establish sessions to that server rather than having to traverse half the network to get to a remote server. Let's talk a little bit about switch port security here. If you go through the switch configuration and set up the port security - again, this is one of these very control-freakish kind of things - it can be effective certain places, but normally you don't apply it across your entire network. Port security on port number 3/1, enable, and then you give it a MAC address. On port 3/2 you just say, "Enable." What that does, the first line, is it explicitly states what the MAC address is that can go for that port. The second line is going to put the switch port into learning mode. The first MAC address it sees is what is - was is going to be applied there. Looking at the show port 3, later on you can see that your security is set up this way. Down at the bottom of that thing, 3/1 is enabled. The secure source address is listed there and the last address seen is also listed there. In port 3/1 they're the same, so has that port been shut down? No it hasn't. Port number 3/2 - you have that secure MAC address that it first learned about, then you have the last source address seen. That's different from the learned MAC address there, so what's going to happen? The switch is going to shut down that port until the administrator can come in and turn that thing back on. Perhaps someone legitimately changed out a NIC or something like that, perhaps not. This is for you to decide how well you really want to implement this. If you have a lot of moves, adds, and changes in your network, this is not for you. It would become an administrative nightmare very quickly. Okay. Switch access security - we've talked about this going to the IOS and the PIX. Here you're going to set up a list that you can permit devices to access some process on the switch itself. First line, set up - set IP permit and address. Second line, set up a network so that anything from the network can come in. Third line, set IP permit enable. Don't use that line first, because if you do that, the list is empty and, of course, you're not on the list, so your session will be terminated. Looking at this whole thing later on - show IP permit. First, it's going to give you back what you configured into it. At the bottom of that thing it's going to give you the list of bad boys out there that have been probing your network. The first one there, someone has tried to do an SNMP query on your machine, on your switch. The second one, someone tried to Telnet into it. Neither of these devices were in the acceptable permitted list, so it logged it and it killed those sessions. You might want to go back and look around, see who's been trying to probe your switch here. Changing for just a second here, let's think about what we've learned. The protection costs - what is it going to be to you if you lose a resource or if that resource becomes either accidentally or maliciously corrupted? How much effort do you need to put into this? Of course, these things are going to be defined by your business needs and by your policy that you establish. All of these have got to merge very well together. The final thought here is the ease of use. If you make your users jump through hoops before they can actually get to the network, they're going to rebel. They're going to find ways around your security mechanisms, conscientiously thinking that, hey, all they want to do is to do their job. Again, make sure everything works back to the business requirements and it's explicitly stated in your policy. Let's expand one more time here and get to the perimeter protection. We've got a picture of the castle here. The drawbridge is up, it's late at night, but you can see a window still has a light shining in it. Perhaps this is a shop that's inside of that castle. What impact is it if no one from the outside can actually get to that shop on the inside? Perhaps none - perhaps a great deal if actually the shop is a major source of revenue for that kingdom. How would you go about addressing this? Would you keep the drawbridge down and post guards to make sure that visitors only walked along the path and only walked into the shop? It doesn't seem to make too much sense. Could you move the shop actually outside the perimeter there, keep the drawbridge up at night, and, you know, if you see a horde of angry bandits coming, just lower the drawbridge, and quick, move the shop back in? That's probably not a real good idea either. Same thing applies to your network. What we have in this diagram is the traditional time-honored design for a firewall and how to present services to untrusted people, let's say across the Internet. Walking through this thing - the green box is the demilitarized zone, this is where you want to offer services. You want to allow people from the outside to come in through your ISP link, through that top screening router, where you put in some access lists and say, "I want inbound sessions to only go to these devices. Specifically, I want inbound sessions on port 80, HTTP, to only go to the Web server. Inbound sessions on port 25 explicitly only go to the mailserver." Then you've got your firewall. Do you want any sessions inbound on that thing? Most likely not. There's some situations where you will. Most likely you want that to enforce your policy for your people going outbound. Use your access lists on both your firewall, your screening router, and make sure you have a switch in there, just in case someone does compromise one of your resources on your - in your DMZ, they will not be able to put up some sniffer software and watch all the other traffic go in between all your other devices. That's been talked about quite some time now. Let's talk about syn attacks coming from the outside. What happens here, this guy - you can tell he's a bad guy, he's wearing a black hat. He is continually sending in - you know, the TCP three-way handshake - he's continually sending in syn packets that he's crafted to this one target. The first one is from 1.1.1.1, the second one, 1.1.1.2, and he just keeps on sending these things in. The target has got to allocate resources every time a syn packet is received. It will then send out the syn/ack packet and wait. Typically it has to wait 75 seconds for the acknowledgment to come back in before it can tear down the resource. A lot of people have had this problem and they've found very good ways to harden the hosts so that they don't have to wait that amount of time, or so that they don't use up as much resources on the server. If this thing succeeds, a lot of these syn packets can come in, actually set up too much processing on that server, and the server could fall over because it just doesn't have anymore resources to allocate. How do we combat this? First, let's look at it - the - just the IOS, and this would be on your screening router out there. The intercept process on the router will watch for syn packets coming in. And the way it works - a syn packet comes in from the outside, the router accepts it and sends back the syn/ack in proxy of the actual resource out there. When it gets the final acknowledgment back in, it turns around and says, "Great, I've got this half session over here. Let me take it over to this side now." I'm going to send a syn packet into the actual resource, I'm going to get the syn/ack back. I'm going to ack that thing, I'm going to take the two half sessions and marry them together, and then get out of the way. The router - the configuration snip is the way to just turn this thing on. You identify your protected resources with an access list there. You don't want to have this access list permit everything because, of course, you don't expect to initiate syn attacks on the outbound side, so you want to protect your resources. Some other options with this - you can get the IOS to see how many session requests have come out in the last one-minute time period and also how many incomplete sessions are there. If the IOS watches these things and there's a default high-water mark - if these two values get above the high water mark - IOS will go into aggressive mode and start shooting down some of these half open sessions until it passes below the low-water mark. And a difference to this, still within IOS, is going into watch mode. This is pretty much the sa - a little bit different here. The syns will come through - IOS is going to allow them to go all the way through to the resource. The resource, by itself, comes back with the syn/ack, and then the ack should follow. If - again, we're doing pretty much the same thing, watching how many session requests have come through in the last one minute, how many incomplete sessions are there, and how long do I wait for that final acknowledgment to come back? If - again, if these - if the high-water mark is exceeded by these parameters, IOS will go into aggressive mode and start shooting down some of the incompleted sessions until it passes below the low-water mark. You can change these default values, start thinking about what your resource can actually handle. How do we do this in the PIX? I've got two configuration snips here. The first one is with the mailhost. Again, that's watching for the SMTP commands. The second one is just done with the static command. What we have at the end of each of these commands is the maximum connections and the embryonic limit. Maximum connections - just what it sounds like, you cannot have any more sessions to that device than are specified in the maximum connections - key word there. Embryonic limit - this is going to say how many half-open sessions you have. Once that limit is reached, no more will be received through the PIX. The IOS Firewall feature set - again, this changes things quite a bit, changes the basic characteristics of IOS. This is going to be - the way it deals with syn attacks is very similar to the way the IOS does in watch mode. It will watch the TCP syns come through, it'll allow them all the way through to the resource. The resource will send back the syn/ack, and it should be followed up with the final ack there. Again, it's watching to see if these high-water thresholds are met. How many session requests, incompleted - how many incompleted sessions there are, and how long does it wait for the final acknowledgment? If these things pass above the high-water mark, it'll go into aggressive mode and start shooting them down again. Okay, moving to something else - the Virtual Private Networking out there. A lot of people are starting to get into this, so let's address this. This has not, in most cases, withstood the test of time like the firewall design. So we're getting some new designs out there. We're getting a lot of new things happening. Let's go through and take a look at the history of these things first. Very, very early on there were the value-added networks. And these things have been great for a lot of companies. Right now a lot of the value-added networks are migrating themselves to using the Internet as a transport. It's still an untrusted transport, so they've got to do some things to maintain their confidentiality, integrity, and various other aspects of the session across it. The alternative is to use the private links, up at the top.  Specifically looking at electronic commerce, we've got an example here of what may be a good way to do this. This is, in fact, Cisco's CCO network. What happens is a user from the outside, across the Internet, establishes a Web session to the internal Web server, or the Web server that's on the DMZ there. That gateway router is a screening router and it's going to only allow traffic to go specifically where you tell it, it can go. And this means that no sessions, all the way from the outside, can come all the way through and hit that firewall. The only sessions that are going to be allowed to go to the firewall and, hence, into the network - into the internal network - are going to be from the Web server. So, outside client hits the Web server, kicks up some processes, the processes on the Web server come in and talk to the secure commerce servers on the inside. There again the firewall is watching these things and will only permit sessions from the secure commerce servers to come back through the firewall to the internal enterprise servers. This way it will be allowed to update the processes in a known fashion to get back whatever that client is looking for on the outside, perhaps delivery dates, perhaps some ordering information. At least it's checkpointed at every case and we've got some rules to say where traffic can and cannot go to. Very, very high level here - the VPN security requirements. We've got a lot of other VPN and VPDN sessions at Networkers here. Very, very high levels - the security requirements for these. Either encrypt the session to provide the authentication, the integrity, and the confidentiality, or move it over to a private line to accomplish the same goals. Looking at the Virtual Private Dial Networks, we're seeing a lot of people starting to work their way into the L2TP, Layer 2 Tunneling Protocol, and some people have actually used the Layer 2 Forwarding as well. Here, this is what we've come up with as the - possibly the best solution for this. You're probably going to have some network address translation problems coming from the Internet out there, going through that gateway router - the screening router again. You want to explicitly say where traffic can and cannot go to. Coming from the outside, if it is a L2TP session, you only want to allow it to go to the home gateway. If it's an outbound session, you only want it - to permit it to come from the firewall and head back outwards as well. Dial Access Protection - a lot of people have asked, "Where should I place the network access server?" Some people have actually said, "It's an untrusted device. Move it all the way out to the DMZ." I don't think this is a good plan. Really, you want the NAS to be inside your network, but beyond a screening router. This is probably the most secure and safest place for it. You don't have to go and start poking holes through your firewall to allow all these sessions coming from your network access server back into your trusted network. Now it's already in there, but you can set up your screening router to make sure traffic only comes and goes to where you want it to come and go to. Okay, let's move on now. Think about some network security sustainment. You've got to have your network running in a secure mode, 24 hours a day, 7 days a week. How can you go about doing that? First one, pretty simple - use dynamic routing protocols and make sure you have enough redundant paths throughout your network. This way it'll route around any failed node. Let's take a look at specifically - well, there's a known type of attack out there that will - someone can craft a route update packet to go in and disrupt the routing tables and perhaps actually bring your whole network down. The way around this is with keyed hashing for authentication and integrity. What happens with this - you start out with a shared secret key. Everyone who's in the pool here knows what this secret key is. If you're not in the know, then you'll never know what the secret key is. You take a message - you take the secret key and the message, put them together, either on top or at the bottom or actually in both places, run it through a hashing function - this is MD5 or SHA1 - come out with a signature. You can send that along with the message to another device out there who's going to do the same thing. They're going to get the message - they have the shared key, so they're going to put it either at the top, the bottom, or the top and the bottom, munch it all together, run it through the same hash function. If the shared - if the signature coming in matches the signature that they generated, then that message is authenticated and it must be correct. How do we apply this to the actual routing updates? First, a router is going to take - it's going to build the route update packet. It'll have the IP header on the front of it and it'll have the key in a certain location inside the payload. It'll take that, run it through the hash function, usually MD5, come out with a signature. That signature has the exact same length as that key. So it'll take the key, throw it away, chunk in that signature in the packet, and then ship that across the wire. First thing another router does when it gets this, it takes that - the signature out, puts it to the side, inserts the key that it also knows, runs that whole thing through the hash function, and comes up with another signature, then compares the two signatures. If they're identical, then you know that you've got authentication and integrity of that packet. We can use this for, let's see, it's quite a list now. It's BGP, OSPF, ISIS, EIGRP, and RIP Version 2. I don't think too many people are actually using RIP Version 2 out there right now. Route Filtering. This is an additional mechanism that you can use. Let's take a look at the configuration snip of this thing. If you have router RIP running and you've got network 10, you can apply distribute list number 1 inbound on this - on your routing process. What this is going to do, it's going to look down for access list number 1, which says deny 0.0.0.0 network, "Deny the default RIP network." So you don't want someone to insert a default network into your router. It will also permit only the 10 network to come into your RIP process. This is going to limit people who might set up a new router and say, "Here is - here's the path to the Internet." Well, those route-up dates will not be accepted by this router. Also, if someone makes a mistake and sets up network 11, this router will never be able to learn it. Looking down in the router, sho ip proto, you're going to see that the incoming update filter list for all interfaces is set to 1. There's various other ways you can apply this thing, you can also apply it to an outbound access for the route updates as well. Overall on your entire network you've got to go back and secure each of the vital resources there. These are three of them that should be given some special consideration. The time service servers that are out there - make sure no one can come in and change the times throughout your entire network. Worst case in a Kerberos network, nothing's going to work again. This could be very detrimental. The Domain Name Servers - again, there are known attack methods. You can see these in the Cert. Advisories all the time. People are poisoning the DNS caches out there. Spend some time, first harden the machine itself, and then set up some protection in front of that thing. Again, the new one that's coming out here are the Certificate Authorities. If you're running an internal intranet based upon Web access so your people can access HR records and things, you want to make sure that your Certificate Authority is pretty rock hard, solid, and no one can get into it and break in. Periodically we get a lot of questions about multilevel security, and this comes from RFC-1108. It goes through and defines things for IPSO, the Internet Protocol Security Options, SIPSO, AESO, DN6, Audit Trail, things like that. In the military, in the DOD networks - vastly used. These things are set up to do that all the time. They've got the support people to make sure this is happening. What happens here is that the - each individual resource, be it a computer, a printer, a file, and everything, is given a label. It's given a security level and some additional key words behind it. This is so that anyone else, any subject coming into this network - they're also given a label and they can only access other resources out there if the labels meet or the subject is higher than the object out there. It's really, really difficult to implement inside of an enterprise network, you know, unless - like I said, unless you're the military or the Department of Defense. I've said a bunch of negative things about multilevel security and the trusted computer security evaluation criteria. That's the Redbook, Orangebook stuff. What positive thing can I say about this? Now let's talk about session protection through encryption now. There's three generally accepted ways of doing this. Starting at the bottom of this diagram, there's the link layer encryption. There are a lot of link layer encryptors out there. They are actually very good. They can take a stream coming in, usually going across a serial link, but I've seen this also across frame relays or Ethernet links, and send it over to another link layer encryptor, which will decrypt it and send it back up to the next higher, the network layer device there. Also, looking at the top of this thing - application layer encryption. I guess the best example of this would be Lotus Notes. When they first came up with Lotus Notes, they identified the security requirements for it and they put in application layer encryption in this for both client/server sessions and for server-to-server database replications. It is - the domestic version of this is 56-bit DES, fairly strong encryption for this. So, within Lotus Notes, Lotus can, in fact, encrypt its own session. To be more generally available and come up with a lot more solutions, everyone is working towards the network layer encryption and this is going to apply to the applica - or the - each of the end nodes out there so that they'll be able to take whatever application, run it through their network layer encryption, and then send it all the way across, peer-to-peer. Or they can send it to a security gateway, which will then decrypt the session and send it in clear text for that last little bit, or in fact, they can have it set up, clear text down to the network layer device, encrypt it across the network, come out to the other security gateway, decrypt it back in clear text going towards the server out there. A lot of this is going through the IPSEC working group within the IETF. Basically how it works - there's first a secure mechanism to exchange shared keys and then the session, whatever will be encrypted, with those shared keys between the two devices. We've got another talk here at Networkers that goes into all the details about this and specifically how it can work for you. NetRanger is a new product we have at Cisco. You can set up sensors throughout your network to watch what's going on. These things have the attack signatures of a lot of different attacks out there and it can identify these or some other problems. And it can take some proactive steps to stop them, including accessing the router to install some dynamic access lists for you. What I show here is a single directory out there, but in fact we've got - or the whole thing is set up so that it can be tiered. There can be a workgroup director which is watching this workgroup. Again, another director over here watching this workgroup. These things at the lowest tier going up a layer, an area director. Several areas are covered by a director by themselves, and then working up to the top layer a - for example, a - your enterprise-wide director. All of these things watching what goes on, on your network and taking care of a lot of the problems that could creep into it, specifically, some attacks. NetSonar is a new product that also is going to help you a lot enforce your security policy. The first thing it's going to do is go out and start mapping your network. It'll go through and look, and this not just a topology map or anything, it's going to go through and actually find what servers are out there, what devices are on your network, and it's going to do some probes on it to find out specifically what services are on these servers. And then it will match that to a database of known attack points and see if that server and service are vulnerable to those attacks. It will then come up with a report that you can look at and see, "Hey, I really need to go over here and take care of this machine because it's open to a known form of attack." Okay, how do we go through and make sure that everything, not only is it working properly all the time, but we want some assurances that it's really, really working all the time? And again, this has got to go back to your business needs. First thing, if you're going through and doing some moves, adds, and changes in your network, you want to model these changes. You want to make sure that you're getting proper access lists in all the routers, make sure they're consistent across the routers, make sure you don't have any empty access lists in any of the routers. An empty access list is, like if you set up an access list 101 and define a bunch of things to it, and then go to the interface, and say, "Access group 102, something or another." There is no access group or access list 102 and you've defined that to the interface. What happens in that case, there is no implicit deny at the end of it. Since it is empty, it allows all packets to go through. NETSYS - the NETSYS modeling tool can look for each of these things and it can give you - it can let you do a bunch of "what if" scenarios so that you can go through and say, "If I add this to the network, will I still never be able to get to that vital resource?" If that's your policy, you can do some "what if" scenarios on it and make sure that that is - that can be accomplished. And, in fact, the NETSYS will spit out all the correct configurations for that. Network management - again, it's not just that box that sits on the side and flashes the colors at you every now and then. You should use this to make sure that you're meeting your policy and your business requirements. Figure out what you need to monitor and what you need to report on from your network management station and come up with those type of reports to say, "Yes, I am meeting my business goals and here exactly is why." Coming down to it, I'm sure you've all seen this old poem. All it's saying here is that the weakest link in your network could be your downfall. It could be an attack point. It could be exploited by either an accident or someone maliciously trying to control your network. Go back and think about where your weak links are in your network and see if you can't protect those things. Keep in mind that security is a foundation service across all of your network. You've really got to think of it that way. Start out by being security conscious as you've designed this network. And then, if you can enforce your policy through your procedures and operations, you should have smooth sailing. Anyway, that concludes our talk. I hope that you all have found some good subject matter in here and I hope this helps you with your network. Thank you very much. </BODY> </HTML>